fbwmfandomcom-20200214-history
User blog:Merricksdad/Proposed storing of sidekick definitions within firefox registry
When I was thinking up the Sidekick docking station for WM 1.5, I ran into a few problems I had to sort out. One of those problems was how to get info about definitions from a source other than the main WM script. I certainly didn't want to have to update the WM script every time any supported game needed a new item added to the options menu. That would have been madness! Ding Dong I determined that the scripts could communicate though a type of little door. The mail carrier could never meet the master of the house, but he could leave a package on the door and ring the bell. The reason the mail carrier could never go inside the house or even talk to the owner is because that mail carrier could be infected or malicious. However, the package could be identified by the owner of the house before opening it. This gave me the idea to create a docking station directly accessible by an outside script, yet one that would not allow malicious script writers access to the WM main body. Personally I don't know how or why anybody would screw with a script like WM to make it do naughy things to your computer, but its certainly possible. And while the docking station idea does not prevent all types of evil, it does limit it to stuff most users could prevent, such as not downloading untrusted sidekicks. My package was not delivered! Since WM 1.5 and its docking station have been out, many problems have come up. One even being documented before the actual release of WM 1.5. That being the OrderBug, also fixable with the Fix1.5 instructions. The problem with this issue is that many of the script users don't know this wiki exists, even though there is a help link right in the options menu to it AND the homepage for the script was changed to this wiki at userscripts.org. Another problem is that many of the users of this wiki dont actually look around and read the wiki before they post a bug or a comment about something not working. That's fine, it just takes a lot longer to get you going again. And its not that I really mind, its just that its kinda crazy to not use a resource that you are actually making a comment on. Space is limited?? Not to bitch or anything, my intent here is to sort out a real problem. Now, the problem is that I would like to (and intended to originally) put all the defs and tests from every sidekick script in storage on your computer. The option values are already stored on your computer, but the menu layouts are not. Nor are the definitions for bonus collection. This means that any time the order of your scripts gets messed up, or for some reason a sidekick doesnt fire, those options are not available and no collection takes place. Really all the instructions are available to fix this problem already and have been available since just after WM1.5 was released. Red Alert! Some technical info follows, so if you are not JavaScript savvy, avert your eyes so you don't get brain burn. All the info for defs and menu layout is created as a JSON object in the sidekick. Then its converted to text before passing to the main script via a known DOM element. This has the following effects: #The menu and defs are created as a JSON object, therefore if the object is improperly fomatted or somehow screwy, the object cannot be converted to text because the object is not available. In effect: the object has a debugging stage before hitting the main script and can raise its own errors which are easy to find for both the writer and the user. #JSON objects converted to text cannot transfer function objects from the sidekick to the WM script. This is good because it prevents malicious scriptwrites from attaching attack buttons to the script or options menu. It does not however prevent a malicious writer from adding a link to a malicious site in the options menu. But the user could check for that before clicking it. (User is warned) #The WM script does not have to update when any new items are added to ANY sidekicks. The only time WM needs to update is when FB changes, scripting language changes, or when a sidekick is built for a game that does not follow one of the known bonus collection methods. And of course I am still adding functionality and other goodies to the main WM script. "She can't take any more captain!" So, the issue really is, do users have enough space in this firefox registry (about:config) to store all the defs and menu layouts, not just the menu values and some bonus collection history? I don't know. I do know that many of the users are just using the FrV sidekick and care less about the others. However, my intent was to eventually have a sidekick for EVERY possible game out there...that is if people wanted to make one. So the potential requirements for multiple sidekick menus and defs could be quite large for any one user. This is why I hesitated to force this method when WM 1.5 was released. My question is: Is storing menu layouts and definitions the way to go? Here are some benefits of doing so (list will be edited as discussion continues): *WM script would function even if sidekick did not fire AFTER wm did. This would remove the order requirements mentioned in OrderBug. *Menu items would appear even if sidekick was not yet available, or temporarily disabled by the user (yes people do this...I do this) Here are some drawbacks: *WM script may attempt to process posts when a sidekick is not actually available (for various reasons) and may waste one-view-only bonuses like those for RwF or CW. I could actually have the WM script ask the sidekick "are you there buddy?" before starting. Would the more programming oriented users please give some input on this subject? Thank you! Category:Blog posts